Le problème : de nombreuses propriétés GA4 ont une part importante du trafic qui est associé à une source (channel grouping) “Unassigned”
Avec l’arrivée de GA4, nous avons remarqué chez plusieurs clients, un nouveau channel grouping : “Unassigned”. Ce traffic, dont on arrive à récupérer que très peu d’informations, deviens très vite gênant lorsqu’il représente la première ou seconde source d’acquisition.
Ici le cas d’un client avec le trafic Unassigned qui représente la seconde source de trafic sur la période.
Je vous détaille ici comment nous avons réussi à résoudre le problème pour nos cas clients. Mais, il peut y avoir aussi d’autres origines à ce traffic Unassigned que je listerai à la fin de l’article.
“Unassigned” ou “(Other)*” ?
*Correspond aux canaux ”(non disponible)” ou “(autre)” dans la version française
“(Other)” était un peu le canal fourre-tout d’UA. Toutes les campagnes dont les paramètres UTMs ne correspondaient pas aux règles par défaut ou préalablement définies étaient catégorisées dans “autre”.
Vous avez dû remarquer déjà que le groupe “(Other)” a disparu dans GA4; il a été remplacé par ce fameux groupe “Unassigned”.
💡
Mais en réalité, ce “channel” regroupe 2 notions :
1- Les sources / médium qui ne sont pas associés à un “channel”, qui se résout assez simplement.
2- La source “(not set)”, qui est beaucoup plus problématique
Concernant le premier point, pour éviter d’avoir du traffic qui se retrouve dans unassigned, il n’y a pas de secret… Vous pouvez :
Améliorer la gouvernance de vos campagnes médias et en particulier de vos paramètres UTMs pour avoir un alignement sur la nomenclature définie par défaut dans GA4
Ajuster les règles de channel grouping personnalisés pour ranger les UTMs égarés
Pour identifier l’origine de ce trafic mal assigné, il suffit d’aller dans le report “Traffic Acquisition” puis, dans le tableau indiquant les données par canal d’acquisition, d’ajouter en dimension secondaire les sources / medium.
Mais passons alors au second sujet : le trafic de source “(not set)”
Désertion des sources d’acquisition
En cherchant à identifier l’origine du trafic Unassigned, vous avez peut-être remarqué la ligne suivante:
Le channel grouping est “Unassigned”, et la valeur de “source/medium” est (not set)
Il s’agit de la valeur par défaut lorsque la valeur de cette dimension est vide, un équivalent du null, en soit. Ce n’est pas du trafic direct, mais du trafic dont on a “perdu” l’origine.
💡
Il s’avère que nos clients où ce phénomène est visible ont pour beaucoup le même point commun :
- consent mode pour gérer le consentement des utilisateurs
- la méthode du reporting identity choisie est “Blended”
Coïncidence vous dîtes ? Pour vous répondre, j’ai repris le cheminement des hits, depuis la console pour vous présenter consent mode, dans BigQuery pour voir la donnée brute (la source de vérité GA4 et si cet article vous suffit pas, lisez celui d’Aristide Riou), et enfin dans l’interface GA4 pour voir une belle conséquence de reporting identity en blended.
La première chose à savoir est que, peu importe si vous avez accepté ou refusé les cookies, un tag GA4 qui utilise consent mode se déclenchera. Pour différencier les hits consentis et non consentis, un paramètre est ajouté: Google Consent Storage (GCS). Il contient 4 caractères: G pour Google, puis 3 chiffres. Dans l’ordre: les cookies essentiels, les cookies analytics et les cookies de retargeting. Chacun a la valeur 1 lorsque consentis et 0 lorsque refusés.
G100: Seuls les cookie essentiels sont déposés
G110: Seuls les cookies essentiels et analytics sont déposés
G101: Seuls les cookies essentiels et marketing sont déposés
G111: Tous les cookies sont déposés
Vous pouvez voir cela directement au niveau du hit de collecte envoyé dans le network.
Hit sans consentement
Hit avec consentement
Cette information est stockée dans la dimension “analytics_storage” que vous pouvez retrouver dans BigQuery avec la fonction suivante:
“No” ou “Denied”, le consentement n’a pas été donné pour ce hit
“Yes” ou “Granted” le consentement a été accordé
Néanmoins, ce n’est pas parce que le hit est collecté que toutes les informations remontent. Si un utilisateur a refusé le consentement alors, il ne sera pas possible de collecter tous les paramètres du hit… ni l’origine du trafic !
Pour voir cela dans BigQuery, il suffit de chercher les dimensions de source ou de medium pour le trafic non consenti d’un côté (”analytics_storage”LIKE‘No’) et le trafic consenti de l’autre (”analytics_storage”LIKE‘Yes’). On voit bien ci-dessous que les sources de trafic sont vides ou “null”.
Ci dessus, on voit qu’aucune source n’est enregistrée pour le trafic “non consenti”
Ici, vous reconnaissez les sources, cela concerne le trafic “consenti”
Mais pourquoi cela serait un problème ? Si la personne n’a pas donné son consentement, ses données ne devraient pas apparaître dans Google Analytics n’est-ce pas ?
Oui, sauf.. dans un cas précis. Lorsque vous avez paramétré votre compte Google Analytics 4, vous avez dû choisir votre méthode d’identification des utilisateurs: Reporting Identity.
L’une des options, “Blended”, vous propose de modéliser des données pour reconstituer les sessions des utilisateurs ayant refusé les cookies. Dans sa doc, Google précise que ce modeling est fait à partir de sessions similaires. Il semblerait tout de même qu’un certain nombre de sessions soient crées artificiellement à partir des hits non consentis, lesquels n’ont pas de source d’acquisition..
Vous commencez peut-être à voir où je vous emmène; comparons BigQuery et l’interface GA4. Sur une même journée, si l’on regarde au niveau de l’évènement de page vue, le total affiché dans l’interface de GA4 correspond dans BigQuery à la somme des hits de page vues consenties et non consenties:
Total de pages vues sur une journée dans l’interface GA4
Total de pages vues sur une journée dans BQ, avec un split en fonction du consentement enregistré
Ces pages vues ne peuvent être associées à des sessions réelles (collectées grâce au consentement de l’utilisateur). GA va donc générer des sessions artificielles mais pour lesquelles il n’aura pas certaines informations comme la source. Ainsi, ces sessions tombent dans le groupe de trafic Unassigned.
On sait donc d’où ce trafic vient, maintenant, que faire avec ?
La solution ici est assez simple: passer en reporting identity de type Device based. Ainsi, vous avez les véritables données brutes, d’utilisateurs ayant consenti à leur collecte. Lâchez prise, acceptez qu’une partie des utilisateurs naviguant sur votre site ne veut pas partager avec vous leurs données, et ne faites pas aveuglément confiance à un algorithme qui est une véritable boite noire. Notez que :
ce changement est rétroactif, vous ne verrez donc pas la courbe se crasher d’un seul coup mais tout votre historique de données sera modifié.
vous pouvez changer de reporting identity autant de fois que vous le souhaitez (à priori)
D’autres origines à votre trafic Unassigned / (not set)
Nous avons ici traité le cas que nous avons rencontré le plus souvent. Il existe malgré tout d’autres situations qui peuvent générer du traffic “Unassigned / (not set)”.
Parmi celles-ci, notons les cas suivants :
Utilisation du “measurement protocol”
Le “measurement protocol” est en réalité l’API de collecte de GA4 à laquelle on envoie directement de la donnée depuis des hits serveur. Afin que ces hits puissent être associés à des sources de trafic, ils doivent d’abord être associés à un ID de session qui a été créé côté client dans GA4… et c’est souvent là que l’implémentation est mal exécutée.
On retrouve pas exemple souvent ce cas dans l’implémentation de GA4 avec Segment.
Il peut également se produire que des implémentations mal maîtrisées créent des sessions pour lesquelles il n’existe pas d’event de “session_start”. Cette situation est décrite succinctement dans cet article :
N’hésitez pas à me contacter si vous avez un cas d’étude différent de celui que je vous ai détaillé. Je me ferai un plaisir de relever le défi !
Les requêtes de cet article
sql
// Récupérer les hits consents et non consentisSELECT
privacy_info.analytics_storage,COUNT(privacy_info.analytics_storage)FROM'matablesource'GROUPBY
privacy_info.analytics_storage
sql
// Récupérer les sources du trafic non consentiSELECT
traffic_source.'source',COUNT(traffic_source.'source')FROM'matablesource'WHERE
privacy_info.analytics_storage LIKE'No'GROUPBY
traffic_source.'source'
sql
// Récupérer les sources du trafic consentiSELECT
traffic_source.'source',COUNT(traffic_source.'source')FROM'matablesource'WHERE
privacy_info.analytics_storage LIKE'Yes'GROUPBY
traffic_source.'source'
sql
// Récupérer le volume de pages vues par type de consentementSELECTCOUNT(event_name),
privacy_info.analytics_storage
FROM'matablesource'WHERE
event_name LIKE'page_view'GROUPBY
privacy_info.analytics_storage
sql
// Récupérer les sources des pages vues par type de consentementSELECTCOUNT(event_name),
privacy_info.analytics_storage,
traffic_source.'source'FROM'matablesource'WHERE
event_name LIKE'page_view'GROUPBY
privacy_info.analytics_storage,
traffic_source.'source'
✍️
L’auteur : Lucie Lafarge
Consultantetracking & analytics chez UnNest, je travaille sur les sujets liés à la collecte et l’analyse de vos données de navigation.
Après 3 années au sein d’une agence dédiée à l'équipe data & analytics de Royal Canin, j’ai pu aiguiser mon sens de l'analyse pour transformer la donnée en actions concrètes.
![[Solved] How to remove not set in Google Analytics 4?](https://www.analyticsmania.com/wp-content/uploads/2023/05/cover-picture-12.jpg)
